Cooperative Task Management Without Manual Stack Management

Perhaps the better of the two is the subtitle for this paper. The idea here is to effectively combine multithreaded programming with event-based programming in order to achieve the 'best of both worlds' concept. Simply, you want to achieve the ease of reasoning allowed for concurrency in the 'even-driven' model, while preserving the readability and maintainability of code associated with 'multithreaded' programming. At a lower level, this exemplifies the differences between manual and automatic stack managing. In the multi-threaded case, automatic stack managing allows for the cur rent state to be kept in data stored on a procedure's program stack while the task is waiting on a blocking operation. Manual stack management, as used by the event-driven model, requires a programmer to rip the code for any given task into event handlers that run to completion without blocking. Their solution is a hybrid approach that enables both styles to coexist in the same code base, using adaptors to connect between them. This allows for a project to be written in one style but incorporate legacy code written in another. The solution was implemented under the Windows operating system using preemptive threads and cooperative fibers. Cooperative task management is achieved by scheduling multiple fibers on a single thread. A scheduler runs on a special fiber called the MainFiber that schedules both manual and automatic stack management code. Both types of stack management code are scheduled by the same scheduler because the Windows fiber package only supports explicitly switching from one fiber to another. When a function, written with manual stack management, calls code with automatic stack management, the caller code is written expecting to never block on I/O, while the callee expects to always block on I/O. To deal with this, a new fiber is created to execute the callee code. The caller resumes as soon as the first burst of execution of the fiber completes. The fiber may run and block on I/O, but when it finishes its work it executes the caller's continuation to resume the caller's part of the task. In this way the caller code does not block while the callee code can at will. On the alternate case, a function with automatic stack management calls a function that manually manages its stack. This case calls for the former function to block fo r I/O, but the latter function simply schedules I/O and returns. To solve this …